A Perfect Demo Environment

A Never Stop Learning! Article

Have you ever said or heard:

“Sorry, I don’t have an example like that in our demo system…”

“No, we can’t show that workflow – this is a demo database…”

“Our demo environment isn’t up-to-date – that’s why this feature isn’t working…”

“No, I don’t have good data to show in this report – no data, in fact – sorry…!”

“That report hasn’t been built for our demo system – but trust me, it’s terrific!”

In your demos, how often do you find you are apologizing for an inability to demonstrate capabilities, complete workflows, or present compelling results and reports? Far too often, in many cases!

A perfect demo environment enables you to show what you need to show, clearly and convincingly. No apologies, no excuses. Accordingly, here are some recommendations for demo environments to make your demos as crisp, compelling and successful as possible.

What’s in this article for you? A lot!

Demo = Fake!
And Don’t Label Things “Demo”
No Obviously Fictional Names
Include Problems, Exceptions, and Opportunities
U.S. vs International
Market Alignment
Market Maturity
Who Am I?
Be a Customer
Keep It Current
Refresh or Reset
Availability
Performance
Surprise – No Internet Access!
“Trust Me…”
Screen and Projection Woes
Mini Mouse
Infrastructure Checklist
A Perfect Demo Environment

Demo = Fake!

One of our objectives in a software demo is to “suspend disbelief.” Anything that looks real helps our cause; anything that appears fake hurts us.

Even though our prospects have asked for a demo (and that we teach demo skills in our Great Demo! Workshops), I recommend avoiding the use of the word “demo” in, well, demos. And in demo environments in particular!

Why? Because customers unconsciously translate “demo” as “fake.”

If it is a demo environment, then it is not real from your prospects’ perspective. Anything done in such an environment is suspect, accordingly!

So don’t call it your demo system, your demo environment, or a similar demo name. Instead, give it the name of a fictional but plausible customer or other realistic-sounding option. (“Apex” is an example we used previously.)

What about using “demo” in other parts of your demo environment?

And Don’t Label Things “Demo”

Anything labeled “demo” in your (ahem) environment causes the same result. Demo = fake.

File names, module labels, login names, forms, dashboards: I’ve seen all these emblazoned with “demo” in one form or another. All these scream “fake!” to our prospects and customers.

Again, use a neutral name or naming convention that looks like a real customer. Much better!

No Obviously Fictional Names

When your prospect sees the names of famous characters in your demo environment, it’s another declaration that “This is fake!”

I recently saw a vendor who used the actors’ names from the full Oceans series of movies, including George Clooney, Brad Pitt, and Julia Roberts (the original cast), plus Sandra Bullock, Cate Blanchett, and Anne Hathaway. All these names were in the vendor demo database. I’ve also seen sports figures, important scientists, authors, and more.

Perhaps it’s easy to remember the names, but they all shout, “This is fake!”

Instead, use realistic names, addresses, and other data. Some demo environments use the names of your organization’s team. That’s a bit better, but it doesn’t take long for a prospect to realize that you and your colleague appear to be responsible for most of the records in your system! (Many startups suffer from this unconscious form of narcissism.)

The strongest approach is to use realistic data that is independent of your company.

A great source for convincing data is to use the data sources created and used by your own organization’s QC team. After all, your QC folks need realistic data sufficient to explore a broad range of testing scenarios. (Hmmm – these should be very similar scenarios to what you need to demonstrate!). A couple of example sources are SQL Data Generator and Mockaroo.

Include Problems, Exceptions, and Opportunities

Status quo is boring.

I’ve seen countless demos that present a dashboard or report that shows everything “looking good.” Everything is “in the green” without any problems or concerns. This is pointless!

You need to show that your tools can find your prospects’ problems and that your software can directly address those problems and enable solutions.

The most compelling demos show examples of how customers can solve their business problems, address outliers and exceptions, and surface and exploit opportunities. This means that your demo environment needs to include good instances of these with good example data:

Problems should be uncovered and presented clearly, providing opportunities for alerts to be generated and sent from your system (just like your customer would use it).
Exceptions should be similarly discoverable, with the appropriate data to explore and determine how to address (just as your customer would investigate).
Opportunities should be readily surfaced and exploitable (just as your customer would pursue).

The more realistic, the better!

U.S. vs International

When I was banished overseas (to Switzerland, tough duty), I realized that our demo environment was entirely U.S. focused. This can be a big “fail” for prospects located elsewhere.

U.S.-based companies often use demo environments that show U.S. maps, list U.S. cities and addresses, U.S. telephone numbers, U.S. currency, U.S. ZIP codes (even the use of the term “ZIP Code” is an example!), U.S. product names, and more. This can be semi-insulting to non-U.S. audiences, and it won’t help your cause.

If you want to sell in Europe, make sure you have Euros, European addresses and postal codes, telephone country codes, and all of the other units and measures that are used in your target countries and markets. (Furlongs per fortnight is one of my favorite arcane units!)

Want to sell into the UK or other English-speaking (but non-U.S.) countries? You may also need to use their local version of English spellings and vocabulary. Now that box is ticked!

Launching into Asia-Pacific? Same guidelines.

You don’t support local languages in these regions? You may want to rethink your strategy!

Very simply, you need to have region-specific data (as appropriate) if you want to build a vision for your prospects of using your tools in the region(s) in which they operate. And, correspondingly, if you are a non-U.S. software company seeking to enter the U.S. market, the same guidelines apply to you as well!

Market Alignment

Have you ever seen a demo presented to a large construction firm that used example data from the banking industry? I did, and the demo utterly failed. The closer you align your demo data to your target markets and verticals, the better:

Best case: Your data, vocabulary, use cases, and demo examples match your prospects’ specific market or vertical.
Next best: Your data, etc., are close enough to your prospects’ specific market that your prospect can make the connection. Important consideration: It is your prospects who decide if your data is “close enough!”
Generally insufficient: Your data, etc., doesn’t bear any resemblance to your prospects’ market. You are asking them to make too large a leap, and their disbelief is no longer successfully suspended.
Really bad: Data that is obviously fake and has nothing to do with the target market. Sadly, this is too often the case!

One successful approach I’ve seen is to have a fairly neutral set of data but also have the ability to configure or customize the screen labels, dashboards, forms, and field names to map to specific markets. There are now products that offer this capability that you should explore (e.g., Saleo). Otherwise, achieving this may require some level of configuration or programming, but the payoff can be high.

An additional note to consider: Customer Success experiences suggest that the further your prospective customers are from your current, successful target markets, the worse the fit and likely represent the highest risk of failed or unhappy implementations. Yes, inappropriate demo data may be a leading indicator of churn!

Market Maturity

Interestingly, prospects at different stages on the Technology Adoption Curve will likely react very differently to demo data. “Technology Adopters” and “Early Adopters” are often very forgiving of the data that is used.

“Early Majority” prospects may be reasonably forgiving, but the further you move to the right, towards and into the “Late Majority,” the more they need to see truly representative data.

Who Am I?

Logging in as “Admin” is another approach that yells “Fake!” to your audience. Many vendors use an Admin logon to enable access to their full range of capabilities.

The only people who log in as “Admin” in real life are, well, the system administrators! This is even more of an issue when vendors start talking about Setup Mode items, such as how “the system can be configured by role for end-users, managers, executives,” etc.

Along similar lines, try to avoid obviously fake names, such as:

Stanley Staffer
Mary Manager
Ernie Executive
Adeline Admin

I’ve seen all four and many more in demos! Do these names look real? Nope. Avoid these and successfully suspend disbelief!

Be a Customer

Seriously.

Some of the best demo environments are “customer” instances, created and maintained exactly the same way as real customers’ environments.

For SaaS organizations, this can be hugely advantageous. Your demo “customer” is treated the same as all the other customers, getting updates, improvements, etc. on exactly the same timeline.

You’ll know your demo environment will be up-to-date and consistent with what all your other customers are using. No surprises…! (Or fewer surprises, at least…!)

Keep It Current

I recently saw a workflow “alert” in a demo that showed a missed task that was 5 years old! Holy old cow! Some manager is going to be very angry if this was real life.

Workflow dates need to appear to be current (or reasonably so). The older the information, the less believable it is.

In many systems, this presents challenges; there needs to be a way to “refresh” demo environments quickly and easily. Again, tools like Saleo may offer automated solutions.

Refresh or Reset

Perhaps one of the hardest tasks for those who maintain demo environments is to keep them current and up to date (and avoid embarrassing problems like that above!). There are several strategies that can be employed:

Review and refresh the data: This relies on somebody periodically working through the relevant data/workflows/alerts/etc. to cleanse outdated bits and update as needed. This is work, but it needs to be done to keep your demo environment as realistic and believable as possible.
Reset: Wouldn’t it be great to simply hit a button and have everything returned to a pristine “zero” state? There are a number of vendors who, in theory, provide these capabilities, including Cloudshare, Skytap, Quali, Qloudable, VMware Workstation, Microsoft Dynamics’ Test Drive, and others. Check them out if you are unfamiliar…!
Alternatively, you may want to create scripts in your own environment to accomplish the same goal.

Availability

In some organizations, demo environments need to be reserved ahead of time (for a range of reasons). In some cases, these reservations may need a day or more in advance.

This can make things challenging for any demos that need to be done in a shorter timeframe or on an ad hoc basis. I’ve heard these environments referred to as having been implemented by the “Sales Prevention Team…!”

In other cases, it may take time to “spin up” a demo environment. This may be unavoidable but troublesome, and you’ll need to plan accordingly.

And, of course, have you ever tried to access your demo environment only to find it “down” or simply unavailable? Not good, particularly if you flew across the country (or ocean) for your most important demo of the year…!

In a demo that I saw recently, the software announced, “Not Enabled for This Demo Account” when the presenter tried to show a specific use case. Even worse, the use case was introduced by the vendor as “here’s something really cool…,” not in response to a prospect question!

Fundamentally, your demo environment needs to be consistently available: You need to be able to count on it to suspend disbelief successfully.

Performance

“…The demo system is slow today because…” Have you ever heard these words in a demo meeting? Have you ever spoken them yourself?

Your prospects will only remember one word: “slow!”

Prospects assume that whatever environment you are using for your demo is going to be better than theirs, often much better. I’ve never heard a prospect say, “Our network is blisteringly fast…!”

In some cases, you may be able to pre-fetch, cache or otherwise out-flank areas of potential performance problems. You’ll want to fully characterize and be closely familiar with your demo environment to know how to prepare.

Best case? Your demo environment is truly “blisteringly fast” and has no visible performance issues: “Wow – look at that! It displayed the results even before we submitted the request!”

Surprise – No Internet Access!

Have you ever found yourself in a situation where you needed access to the web to run your software and found zero connectivity?

Or have you ever been asked to do a demo at a government organization that didn’t allow access through their network?

[This reminds me of the Monty Python Cheese Shop sketch: “Sorry, fresh out…”]

You may need to have backup plans in place for these situations, which might include:

The ability to run your full software from your laptop without any internet connectivity.
Or the ability to use your own “mifi” or “myfi” environment, if allowed.
Or (least attractive, but still a bit of a self-rescue) you’ve captured a healthy set of the key screens from your software into PowerPoint or Keynote that you can share without any network connection to give your prospect a sense of what your system can do.

Whatever you use as a solution, the closer it appears to be your real software, the better you’ll be able to suspend disbelief.

“Trust Me…”

Have you ever heard a vendor say, “Oh, trust me, these reports are terrific…!”

Far too often, I see demos that show reports or dashboards with sketchy data or no data at all! This is even worse when the reports/dashboards are the final screens for important use cases (fail!).

Workflows need to work, reports need to be well-populated, graphs need to be displayed properly, alerts need to be driven by realistic actions, and so on. Your software needs to appear to operate as it would for your prospect as a customer, as much as possible.

Screen and Projection Woes

Have you ever connected to a display or projector (or “beamer”) in a face-to-face demo and been surprised at what happened to your screen? Many meeting rooms and conference facilities have older, lower-resolution projection systems that are insufficient for demos from high-resolution laptops, resulting in invisible buttons, lost portions of your screen, and unexpected scroll bars.

At minimum, characterize the display system you must use so that you can reduce and manage surprises. Be prepared: Practice key portions of your demo in-situ, before the meeting starts.

Even better, if you do a lot of face-to-face demos, consider purchasing and carrying with you a projection device that enables your software to be shown in the best possible light (no charge for this pun!). An investment of a few hundred dollars or euros could save thousands in otherwise wasted time and travel expenses!

Mini Mouse

Finally, consider your mouse cursor: After all, your audience will be trying to watch its movements for an hour or longer in many demos. How visible is it?

You may want to consider increasing its size and/or fill. Most of the default mouse settings on Windows and Macintosh laptops are too small for demos. Explore the options and see what looks best with your software and typical demo scenarios.

Infrastructure Checklist

This is a long article offering a lot of ideas. We’ve explored some aspects of your hardware and software demo environments, but every individual’s situation is unique.

In Great Demo! Workshops we suggest making and using an Infrastructure Checklist to reduce the risk of bad things happening to you in your demos: “The same bad thing should never happen to you more than once, if it is under your control…!”